1. Field
Example embodiments in general are directed to a method of encapsulating information in a database and to an encapsulated database for use in a communication system.
2. Related Art
Conventional databases configured to store user-associated information typically employ a proprietary “record” format. A record includes a number of fields which are uniform throughout a particular database. Records typically include (1) fields used to authenticate or identify users, and (2) fields used to store data associated with the users.
In an example, identifying fields may include a “First Name” field, a “Last Name Field”, a “Social Security Number” field, etc., and/or any other well-known identification/authentication signature (e.g., a biometric signature of a user's fingerprint, retinal scan, etc.). In another example, data fields may include “Credit History”, “Medical History”, etc., and/or any other well type of user-associated data.
Databases using the same record fields can communicate with each other with a standardized communication interface protocol (CIP). For example, first and second Oracle databases may all include the same, or at least compatible, record field structures. The first and second Oracle databases may share information, stored in their respective record fields, using an Oracle-specific CIP because the record field structure of the first and second Oracle databases is known at each database.
However, different databases typically include proprietary record field structures with potentially incompatible CIPs. For example, a non-Oracle database cannot be accessed using the Oracle-specific CIP unless the non-Oracle database employs a “translator” application which converts the Oracle-specific CIP to the non-Oracle CIP, and vice versa. Translator applications are expensive to produce and maintain, and add complexity to inter-database communications. Further, it can be difficult to detect whether another database employs a translator application capable of communication with a source database, such that successful communication cannot be guaranteed.
Record fields are typically stored together in contiguous or adjacent memory address locations, such that identifying fields and data fields are in close, physical proximity to each other within conventional databases. Accordingly, if a conventional database is compromised by a hacker, the hacker can, with relative ease, combine the identifying fields with their associated data fields to obtain the relevance of the data fields.
Conventional techniques to reduce a hacker's success in extracting relevance from compromised data (e.g., by correctly associating compromised data with user-information) typically include adding layers of “active” encryption to database storage protocols. For example, an entire database, storing numerous records, may be encrypted such that the hacker cannot read any information from the database without obtaining a key to decrypt the database.
However, authorized users must also decrypt the database to access the information stored therein, which adds additional processing requirements and delays to database access. Further, if the hacker is able to successfully decrypt the database, the information present within the database becomes available to the hacker in the conventional “ready-to-read” format (e.g., contiguous/adjacent memory address record field storage). Also, if an authorized user loses the key required to decrypt the encrypted database, the authorized user cannot access the database until he/she obtains a replacement key, which can be a laborious process (e.g., requiring re-authentication and distribution of the replacement key).